Closes #641

The bug, confirmed against the live BVG API

crates/hytte-services/src/places.rs's DEFAULT_CONFIG shipped a [[place]] named "Schöneweide" with station = "900180001". Resolving both ids against the live API:

• 900180001 → "S Köpenick/Parrisiusstr. (Berlin)" — a real, different, nearby station. The only S-Bahn line calling there is S3.
• 900192001 → "S Schöneweide Bhf (Berlin)" — the station the place is actually named after.

So the default fetched Köpenick and then filtered for S8/S85/S9, none of which ever call there — a structural, permanent zero-match. The fetch succeeds and the JSON decodes cleanly, so this renders as the plain "no matching S-Bahn departures right now" text (hytte-plugin-departures/src/main.rs's Ok/Stale empty-items arm), not an error — it looks like a quiet evening rather than "I'm misconfigured". That's the entire bug per the issue's triage comment.

Fix: station = "900192001", with a comment naming the station in words right next to the id so the opaque numeric id and the human place name can't silently drift apart again.

lines/directions defaults — decision

I went with Annika's lean from the issue: ship the default with both axes empty/commented out, not populated.

Reasoning: a populated filter that's wrong (as here) fails invisibly — the widget just shows nothing, indistinguishable from an actually quiet station, exactly how #641 shipped for however long. An empty filter (per feed.rs:94-97, empty = allow all) fails visibly and usefully instead — a new user sees every suburban line through the station immediately, confirms the widget works, and only then opts into narrowing it. The previous ["S8", "S85", "S9"] / ["Spandau", "Birkenwerder", "Hohen Neuendorf", "Waidmannslust"] values are kept as commented-out template lines with a note on what each axis does, so the shape is still discoverable.

Tests

• default_config_parses (was pinning the wrong station literal, and the old lines value) now expects 900192001 and empty lines/directions.
• place_transition_silent_on_first_resolution / place_transition_fires_on_genuine_name_change used "900180001" as an arbitrary fixture id for an unrelated "Home" test place (nothing to do with Schöneweide) — swapped for an obviously-synthetic id (900000001) so no test in the file keeps the buggy literal lying around to confuse a future grep.
• New test default_station_id_matches_its_place_name: ties the default place's name ("Schöneweide") to its station id (900192001), with an assertion failure message that spells out the real-world station names (900192001 = S Schöneweide Bhf, 900180001 = S Köpenick/Parrisiusstr., Departures broken #641) so a future editor who changes this literal sees exactly what they're changing and why the old value was a trap. A bare assert_eq! against a self-chosen literal — which is exactly what let this ship — can't catch this class of bug; pinning the id/name relationship can.

Falsification (per the issue's ask)

Reverted station back to "900180001" (only that literal, in DEFAULT_CONFIG) and reran cargo test -p hytte-services places::tests:

places::tests::default_config_parses ... FAILED
places::tests::default_station_id_matches_its_place_name ... FAILED
test result: FAILED. 17 passed; 2 failed; 0 ignored

Then restored the fix and confirmed the file is byte-identical to before the revert (diff clean), and reran the full suite green: cargo test -p hytte-services → 672 passed; 0 failed.

Gates run

• unset RUSTC_WRAPPER && cargo clippy -p hytte-services --all-targets --features system-tests -- -D warnings — clean.
• cargo test -p hytte-services — 672 passed, 0 failed.
• nix fmt twice — 0 files changed both times.

What this does NOT fix

Existing installs are unaffected. write_default_config (places.rs:329) only writes places.toml when the file is absent, so this corrects the default for new installs only. If you already have a ~/.config/trollshell/places.toml with the old 900180001/S8,S85,S9 values (as Annika does), this PR does nothing for it — you need to hand-edit that file yourself (change station to 900192001, and/or drop the lines/directions lines to see everything). This repo intentionally was not touched outside crates/hytte-services/src/places.rs; nothing under crates/hytte-plugin-departures/ changed (its fetch/filter logic was already correct — this was purely a wrong-constant bug in the shipped config), and no config files outside the repo were touched.